Selecting content for a user

ABSTRACT

In one embodiment, a method includes accessing, by a computing device, at least a portion of a user profile that is based at least in part on historical data associated with a user and receiving, by a computing device, data indicative of a current state of the user from a remote system. The current state of the user is the user&#39;s current activity. The method also includes selecting, by a computing device, content by matching one or more attributes of the content to the portion of the user profile and the current state of the user and providing, by a computing device, the selected content for display to the user.

PRIORITY

This application is a continuation of U.S. patent application Ser. No.13/604,377, filed on 5 Sep. 2012, pending, which is a continuation ofU.S. patent application Ser. No. 13/337,468, filed on 27 Dec. 2011,abandoned, which is a continuation of U.S. patent application Ser. No.12/553,522, filed on 3 Sep. 2009, now U.S. Pat. No. 8,103,611, which isa division of U.S. patent application Ser. No. 11/074,157, filed on 7Mar. 2005, now U.S. Pat. No. 7,603,331, which is a continuation of U.S.patent application Ser. No. 09/554,383, filed as PCT Patent ApplicationNo. PCT/US98/24339 on 13 Nov. 1998, now U.S. Pat. No. 6,871,186, and acontinuation-in-part of U.S. patent application Ser. No. 08/970,359,filed on 14 Nov. 1997, now U.S. Pat. No. 6,236,978. The entiredisclosures of each of the applications referenced above areincorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates to a system and method for dynamicprofiling of a user in one to one marketing applications.

OVERVIEW

Many organizations collect historical data about every transaction thatevery customer performs with that organization. Such historicaltransactional data is useful in various one-to-one marketingapplications, such as, e.g., shopping assistant application and dynamicWeb site content presentation. A number of problems have beenencountered in these marketing applications. One such problem relates tothe creation of highly pertinent and comprehensible individual userprofiles that are derived from the historical transactional data. Inaddition, it is also important to have the ability to utilize these userprofiles when the marketing application obtains a current status of theuser. If the user profiles are generated in a highly relevant andcomprehensible manner with respect to a specific user, the applicationswould be able to understand that user's needs better and moreefficiently serve that user.

There are two basic types of user profiles that can be generated—a“static” profile and a “dynamic” profile. The static profile containsall of the factual information of the user including, for example,demographic data (e.g., age, sex, address), psychographic data (e.g.,personality traits and habits), purchasing preferences (e.g., what doesthe user purchase in an average week), etc. Static profiles aregenerated using conventional methods that are known to those of ordinaryskill in the art.

Dynamic profiling information includes specific rules describing theuser's behavior. For example, such rules may include: “whenever user Xtravels to France, user X often buys expensive wines in Paris” or “whenuser Y shops on a weekend and did not buy any groceries for at least 3days, user Y usually purchases a large amount of groceries.” These rulescan be generated with transactional data for each user using variousrule generation methods that are generally known to those of ordinaryskill in the art. For example, one such conventional rule generationmethod is implemented in a rule learning system which generates behaviorrules for individual customers. (See T. Fawcett et al., “Combining DataMining and Machine Learning for Effective User Profiling”, Proceedingsof the KDD '96 Conference, 1996, pp. 8-13).

In order to obtain an extensive understanding of the user, it isdesirable to build both static and dynamic profiles for that user.Although the generation of static profiles is generallystraight-forward, generating dynamic profiles for a large number ofusers may present potential problems. Many transactional systems (e.g.,airline reservations systems, credit card transactional systems and/orWeb site management systems) generate a various number of transactionsfor each user. For example, some systems and/or applications may onlygenerate a dozen transactions per each user, which may not be enough toconstruct a statistically significant and reliable set of rules for aspecific user. Even if there are enough transactions to construct astatistically significant set of rules, these rules should still beverified for their pertinence to the user. Since there can be a largenumber of users, and since the rules generated for each user may not bereliable, there is a problem of verifying a large set of generated rulesfor the users. For example, in a typical system facilitating 5 millionusers and providing about 100 rules per user, approximately 500 millionrules would have to be either stored or processed. Generally, many ofthese rules are either not useful or insignificant. Thus, due to theamount of these generated rules, a rule validation process becomesconsiderably complicated. Furthermore, checking the usefulness of theserules “by hand” becomes practically impossible.

Conventional systems have not successfully provided detailed solutionsto constructing reliable dynamic profiles for the users. One such system(described in T. Fawcett et al., “Combining Data Mining and MachineLearning for Effective User Profiling”, Proceedings of the KDD '96Conference, 1996) provides a limited generation of user's dynamicprofiles. However, this conventional system does not provide acomprehensive method and system for analyzing a large number of dynamicrules, and thus does not provide adequate assistance for the user.

The system and method according to particular embodiments generatedynamic profiles and, thereafter, transforms the dynamic profiles forvarious users into aggregate rules. In particular, “similar” individualrules are compressed into a smaller number of aggregated rules. Becausethe total number of aggregate rules is substantially smaller than thetotal number of individual rules for all of the users, the aggregaterules can be examined manually by a human expert. This expert examinesthese aggregated rules and selects only rules based on the expert'spreferences. Only the individual rules that correspond to the aggregatedrules selected by the human expert are retained in the user's profiles.Since the selected aggregate rules were selected by the human expert, acreation of more accurate dynamic profiles is further assured. Thesystem and method according to particular embodiments thus provide amore useful set of individual rules for each user.

The dynamic profiles generated with the system and method according toparticular embodiments can be used in various systems (e.g., PersonalShopping Assistant and Personal Intelligent Digital Assistant) toprovide better recommendations to the users as to which products andservices each individual user should utilize. Accordingly, the userwould be more satisfied with these systems and the suggestions thatthese systems provide to the user. In addition, Dynamic Web ContentPresentation systems can include the system and method according toparticular embodiments because the users will be provided with betterquality profiles to facilitate the provision of more pertinent Web pagesto the user visiting a particular Web site. Fraud detection systems mayalso include the system and method according to particular embodiments,thus providing higher quality user profiles which may facilitate betterfraud detection. Other applications for the system and method accordingto particular embodiments are also conceivable to those of ordinaryskill in the art.

In addition, the system and method according to particular embodimentsutilizing the above-described rule compression method is not limited toa construction of pertinent dynamic profiles, and can be used in a vastvariety of applications (e.g., construction of high quality associationrules in data mining applications). Other usages of the system andmethod according to particular embodiments are also conceivable to onehaving ordinary skill in the art.

In another embodiment of the system and method according to particularembodiments, the user rules are validated using a processing device.These user rules are retrieved from a storage device. The user rules arethen separated into at least one subset of a user set. Then, it isdetermined if particular rules of the at least one subset is one ofacceptable, unacceptable and undecided based on a defined criteria. Ifthe particular rules of at least one subset are acceptable, theparticular rules of the at least one subset are provided to acorresponding user.

When constructing good dynamic profiles, validation is an importantconsideration. It is possible to construct dynamic profiles forindividual customers using any existing data mining methods. Forexample, an example user rule may indicate that whenever a user buysmilk in the evening, this user also buys onions. It is difficult toascertain if this rule adequately describe the user's behavior. In fact,it may be a statistical coincidence. Therefore, it is preferable toallow the user (or a human expert) to examine groups of the user rules.

Certain example embodiments of example architectures, systems,apparatus, methods, and computer-readable medium according to thepresent disclosure can provide at least one recommendation to at leastone of one or more users and one or more applications usingmultidimensional data. According to the example embodiments of thepresent disclosure, it is possible to access the multidimensional datawhich can define a multidimensional space defined by a Cartesian productof the dimensions. The multidimensional space can have at least threedimensions, and each of the dimensions can be capable of (i) providingvariable information, and (ii) having a type that is different from atype of another one of the dimensions. It is also possible to retrieveinformation from data associated with the multidimensional space.Further, at least one recommendation can be generated based on theretrieved information. Further, according to certain exampleembodiments, at least one of the dimensions can include profiles.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a top level diagram of a process for generating userprofiles.

FIG. 2 shows a flow diagram for generating static and dynamic userprofiles.

FIG. 3 shows a flow diagram of a process for compressing dynamic rules,generating aggregate rules, validating the aggregate rules and creatinguser profiles.

FIGS. 4.1-4.2 show a detailed flow diagram of an example rulecompression process according to particular embodiments.

FIG. 5 shows a detailed flow diagram of an example cluster compressionprocess according to particular embodiments.

FIG. 6 a shows an example system for generating user profiles accordingto particular embodiments.

FIG. 6 b shows a first system for generating the user profiles accordingto particular embodiments as illustrated in FIG. 6 a.

FIG. 6 c shows a second system for generating the user profilesaccording to particular embodiments as illustrated in FIG. 6 a.

FIG. 7 shows a block diagram of an example Personal Intelligent DigitalAssistant system according to particular embodiments.

FIG. 8 shows a flow diagram of another embodiment of the processaccording to particular embodiments in which individual user rules areselectively validated using a selective validation module.

FIGS. 9.1-9.2 show a flow diagram of an example embodiment of a processexecuted by the selective validation module (illustrated in FIG. 8).

FIG. 10 shows a flow diagram of an example procedure to generate theattribute hierarchy and to provide a cluster operation.

FIG. 11 shows a detailed illustration of an example procedure togenerate “Cut” data.

FIG. 12 shows an example procedure for grouping subsets using the “Cut”data.

FIG. 13 shows an example attribute hierarchy which can be utilized withthis embodiment of the process and system according to particularembodiments.

FIG. 14 shows an example illustration of a first level extension and asecond level extensions of an example node/group illustrated in FIG. 13.

FIG. 15 shows an example implementation of the process and systemaccording to this embodiment of particular embodiments as illustrated inFIGS. 8 and 9.

DESCRIPTION OF EXAMPLE EMBODIMENTS

In many customer-related applications (e.g., banking, credit card,Internet marketing applications, etc.), user profiles for each user (orcustomer) are generated to better understand the user (e.g., user'spurchasing trends, business travel locations, types of favoriterestaurants, etc.). A flow diagram of an example process for buildinguser profiles is illustrated in FIG. 1. In particular, informationregarding, e.g., the user's past purchasing history is retrieved in step1. In step 2, user profiles are built, and the process completion issignaled in step 3. User profiles can preferably be generated usingstatic profiles and dynamic profiles. A more detailed flow diagram ofthe process of building user profiles (represented in FIG. 1 by step 2)is illustrated in FIG. 2. The static profile includes user staticcharacteristics (e.g., name of the user, address, telephone number, dateof birth, sex, income, etc.). The static profile is built in step 10using methods known to one having ordinary skill in the art. After thestatic profile is built, this static profile is stored in a separatefile based on the data obtained from the CUST and TRANS files, asdiscussed below. The “CUST” file has the following format:

-   -   CUST(Cust_ID, A₁, A₂ . . . A_(m)),        where Cust_ID is a user identifier that provides an index value        for locating a specific user in the CUST file. A₁, A₂ . . .        A_(m) are fields describing the characteristics of the user        (e.g., sex, income, education, etc.).

The dynamic profile is built in step 15. A dynamic profile consists ofrules (or patterns) characterizing a user's behavior, e.g., “if user Xshops in the evening on weekdays and purchases diapers, user X also buysbeer”, “if user X shops on weekdays, user X usually buys a small numberof items”, “if user X travels to New York on business, user X prefers tohave lunches at expensive seafood restaurants.” The rules are derivedfrom a set of transactions pertaining to a particular user. Thesetransactions may be, for example, credit card transactions, airlinereservations and Web site visit transactions, and are stored in the“TRANS” file which has the following format:

-   -   TRANS(Trans_ID, Cust_ID, C₁, C₂, . . . C_(n))        where Trans_ID corresponds to a unique index key that identifies        the transaction being performed by the user. Fields C₁, C₂, . .        . C_(n) identify a particular transaction (e.g., date of        transaction, time of transaction, amount spent, location of the        transaction, etc.). The field “Cust_ID” corresponds to an index        key pointing to a particular user having a respective record in        the CUST file. Thus, the user performing a particular        transaction can be identified. Other file formats can also be        utilized, as can be understood by those having ordinary skill in        the art. For example, the user-specific information can also be        stored in several files rather than in a single CUST file (thus,        the CUST file can be normalized by splitting the CUST file into        several smaller files). Using different file formats does not        affect the operability of the system and process according to        particular embodiments. After the dynamic profile for a        particular user is generated, this dynamic profile is validated        in step 20.

After the validation of the dynamic profile, the static and dynamicprofiles are combined to form a combined user profile in step 25. Thefollowing example information can be obtained from the TRANS file to beprovided into the static profile when the static and dynamic profiles(the CUST and TRANS files) are combined: a) an average transactionamount for user X; b) user X's favorite brand of beer is, e.g.,Heineken; c) user X shops mostly on weekends.

While it is relatively uncomplicated to construct user static profiles,it is much more difficult to construct quality dynamic profiles. Rulesprovided in the dynamic profile are generated for each user. Because auser may perform only a small number of transactions, the correspondingrules generated may be statistically insignificant, unreliable andirrelevant. In many systems (e.g, airline reservations systems, creditcard transactional systems, or Web site usage systems), it is possibleto have from as little as a few dozen to a few hundred transactions pereach user. The rules generated with such amounts of data are oftenineffective and insignificant.

The total number of generated rules can also be very large. For example,in a system serving 5 million customers and generating an average of 100rules per user, a total number of generated rules can reach 500 million.Many of the 500 million generated rules are of questionable quality andusefulness. In order to filter the rules having such undesirablecharacteristics, a human expert must decide which dynamic rules shouldbe stored and which dynamic rules should be discarded. It would beimpossible for the human expert to manually check the usefulness of all500 million rules.

Quality dynamic profiles are generated by validating dynamic rulesgenerated using various rule induction methods. Ultimately, however, thehuman expert validates the machine-generated rules to determine their“usefulness” in various systems. Since most of the systems generate toomany rules to be manually examined by human experts, the system andmethod according to particular embodiments facilitates compressingindividual rules into “aggregated” rules. After the individual rules arecompressed into the aggregated rules, the aggregated rules are evaluatedby a human expert who selects only the rules that the expert believesare pertinent for the user. In addition, it is possible (in someapplications) that the respective user can be such a human expert (andexamining only the rules that are pertinent to the respective user).

A. Dynamic Profile Construction Procedure

It can be assumed that user-specific rules have been already createdusing methods known to those having ordinary skill in the art. Forexample, individual user rules can be generated using an inductionsoftware system (e.g., “CART” Breiman et al., 1984; C4.5, Quinlan, 1993;or RL, Clearwater & Provost, 1990). The structure of these rules has,preferably, the following form:

C _(i1)θ_(i1) a _(i1) ̂C _(i2)θ_(i2) a _(i2) ̂ . . . ̂C _(ik)θ_(ik) a_(ik)

C _(i)θ_(i) a _(i)  (1)

where C_(i1), C_(i2), . . . , C_(ik), C_(i) fields from the TRANS file,a_(i1), a_(i2), . . . a_(ik), a_(i) constants, and θ_(ij) are relationaloperators (e.g., “=”, “>”, “<”, etc.). In addition, each rule isassigned to a user defined by the Cust_ID (user identifier) from theCUST file.

Next, it is important to remove “useless” individual rules from thetotal number of rules. A process to remove these useless individualrules is shown in FIG. 3. In step 30, individual rules are provided forprocessing. In step 35 several “similar” individual rules (of the form(1)) are compressed into one aggregated rule of the form:

A _(i1)θ_(i1) b _(i1) ̂A _(i2)θ_(i2) b _(i2) ̂ . . . ̂A _(ij)θ_(ij) b_(ij) ̂C _(i1)θ_(ij) a _(ij) ̂C _(i2)θ_(i2) a _(i2) ̂ . . . ̂C_(ik)θ_(ik) a _(ik)

C _(i)θ_(i) a _(i)  (2)

where A_(i1), . . . , A_(ij) are the fields in the CUST file, b_(i1), .. . b_(ij) are constants, and θ_(ij) are relational operators (e.g.,“=”, “>”, “<”, etc.). For each individual rule of the form (1), theaggregated rule of the form (2) is formed after the individual rules arecompressed. The newly aggregated rules (formed in step 40) can be, e.g.,fuzzy rules, and the operators θ_(ij) should also be, e.g., fuzzyoperators. For example, several of the individual rules that are similar(generally pertaining to different users) can be compressed into oneaggregated rule pertaining to the same subject matter that can beapplicable to several users. For example, if several rules have theform:

-   -   IF Shopping_time=“evening” and Day_of_week=“weekday” and        Purchase=“diapers” THEN Purchase=“beer”,        and it is known that most of the users corresponding to this        rule are males, then these rules can be compressed into the        aggregated rule having the following form:    -   IF Sex=“Male” and Shopping_time=“evening” and        Day_of_week=“weekday” and Purchase=“diapers” THEN        Purchase=“beer”.

Additional fields (e.g., Sex, etc.), unlike other fields in the aboveexample rule, are fields from the CUST file. Individual rules relatingto different users can be compressed into the same aggregated rule for agroup of users. Thus, the rule compression can preferably be implementedfor different users. The number of aggregated rules (of the form (2))generated by the compression algorithm should be much smaller than theinitial number of individual rules. Then, in step 45, the aggregatedrules can be validated (one by one) by the human expert (including aparticular user) to determine which rules are appropriate for that user.After the user validates the aggregated rules, this user selects the setof preferred aggregated rules in step 50. Only the individual rulescorresponding to the aggregated rules selected in step 50 are retainedin the user's dynamic profile (step 55) to provide validated individualrules (step 60) to the user.

B. Rule Compression Process

FIG. 4 illustrates a detailed flow diagram of an example rulecompression process (starting from step 35 in FIG. 3). Two individualrules of the form (1) are referred to as “similar” rules if they differfrom each other only in the values of their respective constants a_(ij).Thus, similar rules should have the same number of terms, the samefields C_(ij), and the same comparison operators θ_(ij). Similar rulescan be mapped into the (k+1) dimensional space defined by Dom(C_(i1))× .. . ×Dom(C_(ik))×Dom(C_(i)), where Dom is a domain (or range of values)of the field C, with a rule having the form (1) being mapped into thepoints (e.g., a_(i1), a_(i2), . . . , a_(ik), a_(i)). This set of pointsis generated by similar rules. For example, the rule “if user X shops inthe evening on weekdays and purchases diapers, user X also buys beer”can be written as:

-   -   IF (Shopping_time=“evening” and Day_of_week=“weekday” and        Purchase=“diapers”) THEN Purchase=“beer”.        This sample rule would be mapped into the corresponding vector        (“evening”, “weekday”, “diapers”, “beer”) of the 4-dimensional        space of attributes (variables):Shopping_time, Day_of_week,        Purchase and another Purchase.

The example rule compression process (described below in detail) thengenerates rules (e.g., fuzzy rules of the form (2)). These fuzzy rulesutilize fuzzy linguistic variables for the fields from the CUST andTRANS files, which are generally known to those having ordinary skill inthe art. Each fuzzy linguistic variable has a corresponding identifier(e.g., Income, Transaction_Amount, etc.), each being capable ofproviding a range of values (e.g., natural numbers between 0 and1,000,000), a set of terms (e.g., “low”, “medium”, “high”, etc.), and amembership function that assigns a membership value (e.g., between 0and 1) to each value from the domain of the fuzzy linguistic variablefor each range of values. In addition, the non-ordered fields in theCUST and TRANS files (e.g., “Product_Purchased”) have assignedclassification hierarchies; for example, the field “Product_Purchased”can include standard classification hierarchies used in marketing. Thus,UPCs, e.g., can be grouped into brands, brands can be grouped intoproduct categories, etc.

The following example inputs are provided to the Rule CompressionProcess:

a. Individual rules from users' dynamic profiles.

b. Fuzzy linguistic variables for all fields in the CUST and TRANSfiles.

c. Hierarchical classifications for non-ordered fields.

Example outputs generated by the Rule Compression Process are a set of(preferably) fuzzy aggregated rules having the form (2).

The steps of the example rule compression process shall now be describedin detail with reference to FIG. 4. In step 160, all the individualrules of the form (1) are grouped into sets of similar rules (e,g, ruleshaving the same structure). The maximal number of such similar groups is4^(n), where n is the number of fields in the TRANS file. For example,if n=10, then there can be at most 1×2²⁰ similar groups. However, thisnumber is typically much smaller in practice. Each set of similar rulesforms a set of points in a k-dimensional space generated by theindividual rules described above. In step 165, a group of clusters ofthe generated points is determined using any of the cluster computationmethods known to those of ordinary skill in the art. In step 170,starting from the first cluster of the group of clusters determined inStep 165, an approximate rule for that cluster is determined in Step180. The approximate rule is determined as a function of the points inthe cluster. For example, a point in the cluster may be the “center” ofthe cluster. The center can be identified as a point that minimizes thesum of distances from a particular point to other points in the cluster.For example, given Cluster C_(i)=(c_(i1), c_(i2), . . . c_(ik)), thecenter of this cluster is the point that minimizes the expression:

$\min\limits_{c_{i}}{\sum\limits_{x \in {Clust}_{i}}{d\left( {x,c_{i}} \right)}}$

The center of the cluster can also be determined using other methods,such as, e.g., selecting the most “representative” point in thatcluster.

In step 185, the next cluster is selected and the procedure describedwith respect to step 180 is repeated. In step 175, it is determinedwhether all of the clusters in the group of clusters have beenevaluated. As an illustration, if cluster Clust_(i) contains three3-dimensional points (0,0,1), (0,1,0), (1,0,1), corresponding to thevertices of a equilateral triangle, then the center of this clusterC_(i) the center of the triangle, e,g, the point (½,½,½). Otherapproaches to defining the center of a cluster can be used. This examplerule compression process does not depend on any specific method fordefining any center of a cluster C_(i).

Given the set of rules (1) corresponding to the cluster with the centerC_(i)=(c_(i1), c_(i2), . . . c_(ik)), the corresponding aggregated rulehas the form:

C _(i1)θ_(i1) c _(i1) ̂C _(i2)θ_(i2) c _(i2) ̂ . . . ̂C _(ik)θ_(ik) c_(ik)

C _(i)θ_(i) c _(i)  (3)

which is a “representative” rule for the cluster of similar rules. Forexample, if the center of the cluster is (½,½,½), the following rule isgenerated:

C ₁=½̂C ₂=½

C ₃=½

Also, for totally ordered fields C_(ij), standard deviations σ_(ij) ofthe points in that cluster are calculated for that field. For unorderedcategorical fields C_(ij), a measure of the “deviation” of the points isdetermined in that cluster along the j-th dimension from c_(ij) (byusing the hierarchical classification for that field).

In step 190, a total number of clusters generated in Step 165 isprovided to the user. In step 195, the user is asked if there are toomany of the generated clusters for manually inspecting the aggregatedrules (e.g., the number of generated clusters is greater than apredetermined number). If so, the generated clusters are compressedusing a cluster compression process described in step 205. Thereafter,there is a smaller number of clusters (and corresponding aggregationrules per cluster). The user is asked again, in step 195, if there aretoo many generated clusters for the manual inspection of aggregatedrules. If the number of clusters is smaller than the predeterminednumber, for each cluster C_(i) in step 165 or in step 205, a set ofusers corresponding to the points for that cluster is identified in step210. Each point in a cluster corresponds to a first representative rulefrom the dynamic profile of the user, so that all of the userscorresponding to the dynamic profile rules from that cluster can beidentified. For example, CUST_ID_(i) defined as a set of valuesCust_ID_(ij) corresponding to the users corresponding to the rules ofcluster C_(i). A set of records (“CUST_(i)”) from the CUST filecorresponding to the users of that cluster is identified (e.g., havinguser ID values from the set CUST_ID_(i)). Thus, CUST_(i)={r|CUST(r) andr.Cust_IDεCUST_ID_(i)}.

The set of records CUST_(i) a set of points in m-dimensional space(where m is the number of fields in the CUST file). These points areseparated into clusters using the same techniques as described in step165. For each resulting cluster CUST_(ij), a center is located asexplained below. The set of points belonging to that cluster isapproximated with a logical statement having the form:

A ₁θ_(ij1) b _(ij1) ̂A ₂θ_(ij2) b _(ij2) ̂ . . . ̂A _(m)θ_(ijm) b_(ijm)  (4)

to form a corresponding condition in step 215, where A_(i) the fields ofthe CUST file, θ_(ijl) are relational operators (e.g., “=”, “<”, “>”,etc.) and b_(ijl) are constants. One way to construct the condition (4)would be by finding the center b_(ij)=(b_(ij1), . . . , b_(ijm)) of thecluster CUST_(ij) as described in step 180, and substituting the valuesof b_(ijl) into the condition (4) (also setting all the relationaloperators to be “=”). Another way to construct this condition (4) isdescribed in A. Motro, “Using Integrity Constraints to ProvideIntentional Answers to Relational Queries”, Proceedings of the 15thInternational Conference on Very Large Databases, 1989, pp. 237-246, andC. Shum et al., “Implicit Representation of Extensional Answers”,Proceedings of the 2nd International Conference on Expert DatabaseSystems, 1988.

In step 220, the first and second representative rules are augmented(e.g., expression (4) is augmented with expression (3)). The resultingrule is:

A ₁θ_(ij1) b _(ij1) ̂A ₂θ_(ij2) b _(ij2) ̂ . . . ̂A _(m)θ_(ijm) b _(ijm)̂C _(i1)θ_(i1) c _(i1) ̂C _(i2)θ_(i2) c _(i2) ̂ . . . ̂C _(ik)θ_(ik) c_(ik)

C _(im)θ_(mi) c _(i)  (5)

For example, assume that the center of a cluster is a rule: “if a usershops in the evening on weekdays and buys diapers, the user also buysbeer” (e.g., IF Shopping_time=“evening” and Day_of_week=“weekday” andPurchase=“diapers” THEN Purchase=“beer”). Also, assume that most of theusers in that cluster are men, thus forming the expression (4) where“Sex”=“Male”. Accordingly, the augmented rule is “if a male user shopsin the evening on weekdays and buys diapers, the user also buys beer”(e.g., IF “Sex”=“Male” and “Shopping_time”=“evening” and“Day_of_week”=“weekday” and “Purchase”=“diapers” THEN“Purchase”=“beer”).

Then, in step 225, the rules of the form (5) generated in step 220 areconverted into fuzzy aggregated rules. In particular, each field A_(i)and C_(ij) in the form (5) is mapped into a corresponding fuzzylinguistic variable associated with that field. In addition, all of theterms in the expression (5) are converted into appropriate fuzzyexpressions. For example, assume that a non-fuzzy term A₁=20 correspondsto a fuzzy linguistic variable also denoted as A₁. Further assume thatthe term set for A₁ is either low or high, and that there is amembership function that assigns the membership value (e.g., between 0and 1) to each value from the domain of fuzzy term A₁ for each valuefrom the term set. Then, it can be determined for which term (e.g., lowor high) the membership value 20 is higher, and a corresponding term isassigned. If the membership value is higher for the term “low”, then theexpression A₁=20 is replaced by A₁=LOW.

In step 230, the set of aggregated fuzzy rules generated by the rulecompression process is shown to the human expert who selects only themeaningful and useful rules from this set according to user desiredcriteria.

C. Cluster Compression Process

FIG. 5 shows an example cluster compression process as discussed abovewith respect to step 205 illustrated in FIG. 4. As an initial matter, itis assumed that, e.g., clusters Clust₁ and Clust₂ are determined in step165. Since Clust₁ and Clust₂ can be generated by dissimilar rules, therules from each of these clusters Clust₁ and Clust₂ can be verydifferent (or similar). Therefore, it is important to determine whethertwo different clusters are substantially similar to each other so thatthey can be merged. In particular, the distance between two aggregatedrules of the form (3) corresponding to the centers of these clusters isdetermined to ascertain whether these different clusters aresubstantially similar. As an example, the following two aggregated rulescorresponding to the center of Clust₁ and Clust₂ are considered:

C ₁ =âC ₂ <b

C ₄ =c, and

C ₁ =d̂C ₃ =e

C ₄ =g

It may be also assumed that the domains of attributes C₂ and C₃ arediscrete and ordered. These rules have different structure and thereforeare different. In order to calculate the distance between these rules,we first have to bring these rules into the same 4-dimensional space ofattributes C₁, C₂, C₃, and C₄. This can be done by replacing these ruleswith the rules

C ₁ =âC ₃ =ẑC ₃ =x

C ₄ =c  (6)

C ₁ =d̂C ₂ =ŷC ₃ =e

C ₄ =g  (7)

where x and y are uniformly distributed random variables ranging overthe domains Dom(C₃) and Dom(C₂) of attributes C₃ and C₂ respectively andz is a uniformly distributed random variable ranging over the domain ofDom(C₂) from its smallest element to b. This procedure can also beperformed using actual distribution in the data for correspondingattributes of x and y variables. It should be noted that the term C₂<b(the first aggregated rule described above) should be replaced with C₂=zin rule (6). In addition, term C₃=x is provided into the firstaggregated rule and term C₂=y is provided into the second aggregatedrule. It is also assumed that, e.g., random variables x, y, and z areuniformly distributed over their respective domains.

If constants are substituted for the variables x, y, and z, the terms ofthe aggregated rules (6) and (7) will contain only equalities andconstants. Thus, these aggregated rules (with the above-describedsubstitutions) will have respective points in the same 4-dimensionalspace. If the distance between these two points can be calculated forfixed values of variables x, y, and z—(Clust₁ (x,z), Clust₂ (y)) (e.g.,if all the attributes are numeric, then the distance can be a Euclideandistance; if some of the attributes are categorical and unordered, thedistance can be calculated in terms of how far the nodes are in theaggregation hierarchy defined for that attribute)—then the distancebetween clusters Clust₁ and Clust₂ is equal to:

${d\left( {{Clust}_{1},{Clust}_{2}} \right)} = \frac{1}{\begin{matrix}{{{Dom}\left( C_{2} \right)} \times {{Dom}\left( C_{3} \right)} \times \left( {b - {\min \left( {{Dom}\left( C_{2} \right)} \right)}} \right) \times} \\{\sum\limits_{{x \in {{Dom}{(C_{3})}}},{y \in {{Dom}{(C_{2})}}},{z < b}}{d\left( {{{Clust}_{1}\left( {x,z} \right)},{{Clust}_{2}(y)}} \right)}}\end{matrix}}$

since it can be assumed that the domains of attributes C₂ and C₃ arediscrete. If these domains were continuous, integration would have beenused instead.

In general, let c₁=(c₁₁, c₁₂, . . . c_(1k)) and c₂=(c₂₁, c₂₂, . . . ,c_(2m)) be the centers of two clusters Clust₁ and Clust₂ as calculatedin steps 170 through 185 illustrated in FIG. 4, where c₁ and c₂ arevectors with different dimensions (because different rules can havedifferent numbers of terms). The rules corresponding to the centers ofthese two clusters are extended with, e.g., dummy attributes and dummyrandom variables that form a union of the attributes for clusters Clust₁and Clust₂. Assuming that the dummy variables are uniformly distributedover their domains, the distances between the two rules for fixed valuesof random variables can be calculated. Thereafter, the random variablesare either integrated (for continuous random variables) or summed (fordiscrete random variable) over different values of these randomvariables. Thus, the distance between clusters can be determined usingthe system and method according to particular embodiments.

Once the distance between the two clusters is determined, the clusterscan be merged as follows. In order to perform this operation, the sizeof the cluster should be determined as a part of the Cluster Compressionprocess. The size of the cluster is the measure of how far the points ofthe cluster are apart from each other. This size can be determined,e.g., using the following formula:

${{size}({Clust})} = {\frac{1}{{Clust}}{\sum\limits_{x \in {Clust}}{d\left( {x,c} \right)}}}$

where c is the center of the cluster. Other measurements can also beused by those having ordinary skill in the art.

The flow diagram in FIG. 5 illustrates an example process forcompressing clusters. In particular, two clusters Clust₁ and Clust₂ areselected in step 250. There are a number of ways to determine whichclusters should be selected in step 250. The simplest way to select theclusters is in an arbitrary manner. In step 260, the distance betweenthe clusters is determined, as discussed above. In step 265, therespective size of each cluster is determined. In step 270, a check isperformed to determine if the distance between the clusters {d(Clust₁,Clust₂)} is smaller than the sizes of these clusters (e.g., to determineif these two clusters are “close enough” to each other). If so, theclusters should be merged into one cluster in step 275; otherwise, theclusters are maintained as separate clusters. In particular, an inquiryas to whether two clusters are “close enough” can be computed in thefollowing manner, e.g.:

$\begin{matrix}{\frac{2 \times {d\left( {{Clust}_{1},{Clust}_{2}} \right)}}{{{size}\left( {Clust}_{1} \right)} + {{size}\left( {Clust}_{2} \right)}} < \alpha} & (8)\end{matrix}$

where α is a predetermined threshold value. The two clusters should bemerged by forming a new cluster consisting of points from Clust₁ andClust₂ if condition (8) occurs. Steps 250-275 should be repeated untilthere are no more clusters left that can be merged (see step 255).

In deciding which clusters Clust₁ and Clust₂ should be chosen in step250 of the cluster compression process, distances between, e.g., allpairs of clusters can be calculated and condition (8) can be checked toascertain which clusters should be merged. Other methods to select theclusters for compression can also be used. Furthermore, the distancebetween all the pairs of clusters does not necessarily have to becalculated.

The system according to particular embodiments can be used in a PersonalShopping Assistant (PSA), a Personal Intelligent Digital Assistant(PIDA), and in a dynamic Web content presentation system, describedbelow.

A Personal Shopping Assistant (PSA) system according to particularembodiments provides recommendations on the products and services thatits users should consider purchasing (including, e.g., suggestions forpurchasing at a specific source, and at a particular price). An exampleembodiment of the PSA system according to particular embodiments isshown in FIG. 6 a. In particular, the system includes a User TransactionCollection and Recording Unit (or module) 115, a Past Purchasing HistoryStorage Unit (or module) 120, a User Profile Generation module 110, aState-of-the-World module 150, a User Estimated Purchasing Needs module140, a Purchasing Recommendations module 145, and the State-of-the-Usermodule 160.

The User Transaction Collection and Recording Unit 115 collects most ofthe shopping transactions performed by the user (e.g. 80-90% of all thepurchases made by the user). The User Transaction Collection andRecording Unit 115 can be implemented as a “smart card,” or as a smartPoint of Sales register that records individual items purchased by theuser. Alternatively, the user himself can record this information (aspart of the User Transaction Collection and Recording Unit 115) usingsome transaction recording systems such as Quicken or Microsoft's Money.

When the user purchases one or more products, the User TransactionCollection and Recording Unit 115 records and transmits this informationto the Purchasing History Storage Unit 120 where this information isstored as part of the purchasing history of the user. The PurchasingHistory Storage Unit 120 can be implemented, e.g., as a database thatrecords transactions performed by various users in the TRANS file, asdescribed above.

Information stored by the Purchasing History Storage Unit 120 isprovided to User Estimated Purchasing Needs module 140. In order toestimate the user's purchasing needs, pertinent static and dynamicprofiles of the user should be constructed based on the past purchasinghistories obtained from the Purchasing History Storage Unit 120, whichis performed by the User Profile Generation module 110. Static profilesinclude the user's demographic information (e.g., age, sex, maritalstatus), particular preferences (e.g., user prefers a particular brandof beer), and certain purchasing decisions (e.g., the user bought aparticular automobile in a particular month). Dynamic profiles include aset of rules (e.g., “if a user goes to France, the user often buysperfumes in Paris”, “if user Y visits a Web site from the site Z in theevening, user Y does not spend a predetermined amount of time at siteZ”, etc.).

In addition, the PSA system maintains information on the current Stateof the World using the State-of-the-World module 150, which recordsinformation, e.g., on a broad range of products and services offered byvarious suppliers and on promotions and discounts run for these productsand services. Also, the PSA system includes the State-of-the-User module160 that maintains information about the user obtained from thePurchasing History Storage Unit 120 (e.g., the user will be in New Yorkon Jun. 28, 1995 because she purchased an airline ticket for that dateand destination) and various external information (e.g., the date, time,and the user's location, if available).

By knowing the purchasing history of a user (provided from thePurchasing History Storage Unit 120), the user's profile (provided fromthe User Profile Generation module 110), and the external informationabout the user (provided from the State-of-the-User module 160), the PSAsystem estimates the user's future purchasing needs using the UserEstimated Purchasing Needs module 140. This Estimated Purchasing Needsmodule 140 may match the rules specifying which products the user willbuy (and when) with the user's purchasing history. As a result, a set ofproducts that the user should consider buying is produced.

Once future purchasing needs are estimated in Step 140, the PSA systemwill match these needs against a broad range of products and servicesoffered by various suppliers and on the promotions and discounts run forthese products and services. This matching process is performed by thePurchasing Recommendation module 145 using conventional methods that areknown to those of ordinary skill in the art. For example, if the userneeds to buy a pair of jeans within the next two months, the PurchasingRecommendations module 145 selects the merchants selling jeans, e.g, thecheapest pair of jeans that fits the use's requirements (considering thepromotions offered within the next two months) by matching to the userprofile (e.g., the user's purchasing needs). Once the PurchasingRecommendations module 145 matches the user's purchasing needs againstthe products and services, the Purchasing Recommendations module 145provides purchasing recommendations to the user.

For example, based on the past purchasing history of a particular user,the PSA service may ascertain that whenever user X goes to France, userX often buys perfume in Paris. This rule is stored as a part of the userprofile using the User Profile Generation module 110. In addition, thePurchasing History Storage Unit 120 of the PSA service may receiveinformation that the user has purchased a ticket to Paris, and in asubstantially same time period, the State-of-the-World Unit 150 of thePSA service also receives information that, e.g., Christian Dior haslaunched a new line of perfumes that is similar to the brands previouslypurchased by user X. In addition, the State-of-the-World Unit 150 mayalso receive information that the duty-free shop at Charles de Gaulleairport is having a sale on these new perfumes (the price being verycompetitive). Using the above-described example information, the PSAservice (using the User Estimated Purchasing Needs module 140) estimatesthat user X may want to buy these perfumes and sends a message to user X(via the Purchasing Recommendation module 145) to consider purchasingthe new perfume at the duty-free shop at Charles de Gaulle airport.

The success of the PSA service depends primarily on accurate predictionsby the PSA service of users' future needs. If the user finds, e.g., 50%of the PSA suggestions useful, the user will probably be satisfied withthe PSA service. However, if the user finds, e.g., only 10% of thesuggestions to be useful, the user will, most likely, reject thisservice. As indicated above, in order to make predictions of the user'sfuture needs more accurate, it is important to build reliable userprofiles. Particular embodiments provide a method and system forgenerating better dynamic profiles and, therefore, providing moreaccurate predictions of the users' future needs.

The PSA system illustrated in FIG. 6 a can be implemented using a firstexample system shown in FIG. 6 b and a second example system shown inFIG. 6 c. The first example system of FIG. 6 b provides that the UserTransaction Collection and Recording Unit 115 is stored on the clientside. All other modules from FIG. 6 a are stored on the server side andare connected to the User Transaction Collection and Recording Unit 115via a Telecommunication Medium 130 (e.g., a telephone line or a wirelesscommunication medium). In the first example system, individual userpurchasing histories and static and dynamic profiles of these users arestored on the server at a central location (e.g. a database), and themethod and system according to particular embodiments (as describedabove) generates improved dynamic profiles, and thus provides betterestimated purchasing needs of the users.

The second example system of FIG. 6 c provides that the User TransactionCollection and Recording Unit 115, the User's Profile Generation Module110, the Purchasing History Storage Unit 120, the State-of-the-Worldmodule 150, the State-of-the-User module 160, and the User EstimatedPurchasing Needs module 140 are stored on the client side, while theState-of-the-World module 150 and the Purchasing Recommendations module145 are stored on the server side. In the second example system, theuser dynamic profiles are validated in Step 20 of FIG. 2 by the user(since these profiles are stored on the client side and are available tothe user for checking and validating). Once module 140 estimates userpurchasing needs, these estimated user purchasing needs are transmittedvia the Telecommunication Medium 130 (e.g., a telephone line or awireless communication medium) to the server, where the estimated userpurchasing needs are matched by the Purchasing Recommendation module 145to various products and services offered by various suppliers (that arestored on the server side). The resulting purchasing recommendations aretransmitted back to the client side via the telecommunication medium 130for the user's consideration.

The PSA service can also be used in a Personal Intelligent DigitalAssistant (PIDA) service as illustrated in FIG. 7. Each user subscribingto this additional service is provided with a Personal Digital Assistant(PDA) (e.g., the remote device 350 or the User Transaction Collectionand Recording Unit 115), which is connected to the PSA system (e.g., ageneral purpose computer 300). The PDA remote device(s) 350 (whichincludes, e.g., a PDA processor 360, a PDA I/O port 365 and a PDA inputdevice 355) and the PSA system(s) 300 (which includes, e.g., a displaydevice 310, a storage device, a PSA processor 320, a PSA/I/O port 325and a PSA input device 305) form a client-server architecture, in whichthe PDA remote device is a client and the PSA system is a server. ThePSA system, using the Past Purchasing History Storage Unit 120 (e.g., astorage device 315) and the User Profile Generation module 110, theState-of-the-World module 150, the State-of-the-User module 160, theUser Estimated Purchasing Needs module 140 and the PurchasingRecommendations module 145 (executed by, e.g., a processor 320)estimates users' future needs and behavior as described above. The PDAdevice accumulates additional information on the user's current state,such as the user's location information, preferences, and desires (e.g.,the user is hungry now and wants to eat). This additional information istransmitted from the PDA device to the PSA system via thetelecommunication medium 130 (e.g., a wireless network, fiber-opticscommunication system, telephone wired system, etc.) to be stored usingthe State-of-the-User module 160 (e.g., in the storage device 315) aspart of the user's state and is used subsequently for estimating theuser's purchasing needs.

For example, in order to illustrate how the PIDA service operates,assume that it is Tuesday, 11:30 am and that user X is driving in hiscar on I-87 in the Albany region on business, and that he indicatedthrough his PDA device 350 that he wants to have lunch. The PDA device(350) records the current state of user X as “Tuesday, 11:30 am,presently driving in user X's car on I-87 in the Albany region, travelpurpose is business, wants to have lunch.” This information is sent fromthe PDA device 350 to the PSA system 300 via telecommunication medium130. Based on user X's past purchasing history, the PIDA servicerecognizes that whenever user X is traveling on business, he likes tohave light lunches at good quality restaurants and that he generallylikes sea food. By examining user X's personal profile, and by matchingthe dynamic rule which provides that “whenever user X travels onbusiness, he prefers light lunches at good quality restaurants”, withuser X's current state (user X is currently traveling on business), thePSA system 300 can predict that user X prefers a lunch at a good qualityrestaurant and he wants to eat light food. Next, the State-of-the-Worldmodule 150 of the PSA system 300 searches for highly rated seafoodrestaurants in the Albany region. If the PSA system 300 finds any suchrestaurant, user X is provided with restaurant choices (e.g., if morethan one restaurant is located) by contacting user X's PDA device 350.If the PSA system 300 does not find first choice restaurants conformingto the user X's preferences, the PSA system 300 provides second choicerestaurants to user X.

User needs are estimated based on purchasing history, the user's staticand dynamic profiles and the current “state” of the user (sent to thePSA system from the PDA device). When the needs of the user areestimated (e.g. the user wants to buy a perfume in Paris, or wants toeat at a good seafood restaurant in the Albany region), they are matchedwith the current state of the “world.” If the PIDA service finds goodmatches (e.g., Christian Dior perfumes are on sale at Charles de Gaulleairport in Paris, or that there is a good seafood restaurant in theAlbany region serving special lunches and located very close to theuser's current route), purchase recommendations are provided to thecustomer based on these matches. These recommendations are sent backfrom the PSA server 300 to the PDA device 350 via a telecommunicationmedium 130 (e.g., via e-mail or through another intelligent userinterface).

The PIDA service incorporating the system and method according toparticular embodiments can be used for notifying the users about variouspurchasing opportunities, both time sensitive (e.g., a particular salewill start next week) and spatial (e.g., if you need a new sweater, andsweaters you would probably like are on sale at the store near yourwork).

The system and method according to particular embodiments can also beincorporated in a Web site system. In conventional systems, when a uservisits a particular Web site, the user usually sees the same contents,regardless of who the user is. Using the system and method according toparticular embodiments (e.g., individual profiles for respective users),the dynamic Web content of the Web site presented to the user can bevaried to conform to the dynamic profile of the user visiting the Website. Furthermore, dynamic profile construction methods can also be usedin fraud detection systems. In particular, a set of fraud detectionrules can be dynamically generated for each user.

It should be noted that the use of the above-described rule compressionprocess and the cluster compression process according to particularembodiments is not limited to a construction of user profiles. Forexample, these process can also be used for computing useful associationrules in data mining applications, or in general compressing large setsof rules generated by data mining algorithms.

D. Selective Validation Procedure

Another embodiment for providing a selective validation of individualuser rules is shown in FIG. 8. In particular, user rules for allindividual users (e.g., customers) are provided to a selectivevalidation module/arrangement (step 375). The selective validationmodule/arrangement can be preferably executed by a central computingdevice illustrated in FIGS. 6 a and 6 b, or executed by the processor320 of the general purpose computer 300 illustrated in FIG. 7. Theindividual user rules may be stored in the storage device 315. It isalso possible to provide the selective validation module/arrangement inthe remote unit 350 illustrated in FIG. 7. In step 380, the selectivevalidation module/arrangement receives still unvalidated user rules andoutputs at least one set of selectively validated individual user rules(step 390). In addition, the selective validation module/arrangement canoptionally include the process illustrated in FIG. 3. In an exampleembodiment, this selective validation procedure allows the human expertto select particular subsets of individual user rules and characterizethese subsets as “Good” subsets, “Bad” subsets and/or “Undecided”subsets.

A flow chart representation of an example embodiment of a processexecuted by the selective validation module (or an example stepsexecuted by the selective validation arrangement) described above isillustrated in FIG. 9. According to particular embodiments, a“Good_Rules” set is provided to maintain (e.g., store) all sets ofindividual user rules which were selected by the human expert as ruleswhich are usable for a particular user. A “Bad_Rules” set is provided tostore all sets of individual user rules selected by the human expert tobe unusable for that user.

As shown in FIG. 9, (in step 400) each of the “Good_Rules” and“Bad_Rules” sets are initialized, e.g., to be empty or null sets. Instep 405, all user rules are combined to form Set S. Set S initiallycontains all related (e.g., similar) subsets of the unvalidatedindividual user rules for all users. These similar subsets may begrouped in a similar manner as discussed above with reference to FIG. 4,or using a filtering and/or clustering operator as discussed below. Instep 410, the user rules in Set S (or subsets in Set S) can bedisplayed. The human expert examines the subsets of “related” rules fromSet S (e.g., one rule or one set at a time), and selects which subsets(or which rules) in Set S are “good”, “bad” and/or neither (step 415).These subsets can also be examined automatically by a system (e.g., theprocessor 320 implementing an expert system or an artificialintelligence system) using a predetermined criteria. If a particularsubset in Set S is selected to be usable, the particular subset ismarked as “good”; if this subset is selected to be unusable, it ismarked as “bad”; if the human expert (or the system) cannot determine ifthe particular subset is usable or not, such subset is marked as“undecided” (step 420). In step 425, the subsets which are marked as“good” are moved from Set S to the Good_Rules set, and the subsets whichare marked as “bad” are moved from Set S to Bad_Rules set.

In step 430, a decision is made (e.g., automatically via the processor320 or by the human expert) if the processing of the selectivevalidation module/arrangement is completed, and, if so, initiates acompletion process according to particular embodiments. There can benumerous conditions to indicate to the selective validationmodule/arrangement according to particular embodiments that thecompletion process should be initiated. For example, the followingexample conditions may prompt the selective validationmodule/arrangement to stop processing:

-   -   Set S can became empty (e.g., all subsets of rules are moved        from Set S to “Good_Rules” set and/or to “Bad_Rules” set). If        this is the case, all subsets of rules are marked with their        appropriate designation (e.g., “good” or “bad”);    -   the number of subsets in Set S is less than a predetermined        number;    -   the ratio of the rules in Set S with respect to all of the        existing rules is less than predetermined value; and    -   the user decides to stop the process (e.g., a desired number of        rules has already been classified or marked).        Other stopping criteria may be used for initiating the        completion process according to particular embodiments.

If it is determined that the processing of the completion processaccording to particular embodiments should be initiated, the rules fromthe Good_Rules set is assigned to one or more corresponding users (step435), Good_Rules set and/or undecided subsets can be displayed (step440), and the execution of the process according to particularembodiments is stopped. If, however, it is determined that thecompletion process should not be initiated (e.g., the subsets should beregrouped), the remaining rules in Set S (e.g., the subsets marked as“undecided”) are grouped or regrouped to generate a new Set S (step445), and this new Set S is provided to the human expert (e.g., loopedback to step 410) so that the rules within new Set S may be reclassifiedusing the process and/or the arrangement according to particularembodiments (e.g., looped again starting with step 410).

It should be noted that if a particular subset Set S is marked as“undecided”, this subset is then further analyzed by either splitting itinto smaller subsets using techniques described below or optionallyregrouping this particular subset with other related sets from Set S asalso described below.

According to an example embodiment of the process according toparticular embodiments, the rules in Set S which were marked as“undecided” are grouped to generate a new Set S according to thefollowing example methods:

-   -   A predetermined number of the remaining subsets (which can also        be a single subset) contained in Set S are selected and merged        together to form new subsets. The above-described remaining sets        can be selected by the human expert or according to some        predetermined selection criterion (e.g., the size of individual        sets of rules should be smaller than a predetermined value).    -   One or more subsets are selected from Set S. For each of these        subsets, at least one of the following example “partitioning”        operators is applied to the selected subsets: a filtering        operator and/or a cluster/grouping operator (which are as        described below). Other “partitioning” operators can also be        implemented. The terms—“clustering operator” and “grouping        operator refer to identical operations and shall be utilized        interchangeably below. In a particular embodiments, subsets in        Set S (obtained using the cluster operator with a particular        “cut” operator) can be re-grouped based on a different “cut”        operator, which may depend from the previous cut and/or can be        based on other parameters or criteria. For example, these        subsets can be merged back into a single set of rules and the        cluster operator is then applied to this subset again (but with        a different “cut” parameter). Other operators can also be used        to regroup the subsets in Set S.

I. Filtering Operators

An example filtering operator receives a subset of rules and splits thissubset into at least 2 subsets: one subset contains rules which pass apredetermined selection criteria of the filter, and another subsetcontains rules which do not. In particular, this selection criteria maybe specified using a data mining query (or a pattern template). The datamining query describes a class of patterns in general terms.

Data mining queries are described in publications—T. Imielinski et al.,“DataMine: Application Programming Interface and Query Language forDatabase Mining”, Proceedings of the Second International Conference onKnowledge Discovery and Data Mining, August 1996; J. Han et al., “DMQL:A Data Mining Query Language for relational Databases”, Proceedings ofthe SIGMOD Workshop in Research Issues on Data Mining and KnowledgeDiscovery, Montreal, June 1996; and W. Shen et al., “Metaqueries forData Mining,” Advances in Knowledge Discovery and Data Mining, chap. 15,AAAI Press, 1996. Any pattern description language or any data miningquery language can be used to specify patterns and data mining queries.For example, article by T. Imielinski et al., “DataMine: ApplicationProgramming Interface and Query Language for Database Mining,”Proceedings of the Second International Conference on KnowledgeDiscovery and Data Mining, August 1996 introduced “M-SQL” forassociation rule discovery which is based on software query language(“SQL”) modified with additional data mining operators. However, theexample embodiment of the data mining query does not depend on anyspecific language.

For the following example request, “Find all rules in customer purchasedata specifying which product categories the customers with children ofvarious ages are buying”, M-SQL query is as follows:

-   -   SELECT *    -   FROM Mine(CustomerPurchaseData) R    -   WHERE R.Body<{(Children=*), (ChildrenAgeLess6=*),        (ChildrenAge6to12=*), (ChildrenAgeMore12=*)} and        {(Children=*)}<R.Body and R. Consequent IN {(CategorySweets=*),        (CategoryCereal=*), (CategoryFruit=*)} and R.Confidence>=0.5 and        R.Support>=0.01.        This data mining query discovers association rules if and only        if they satisfy certain criteria. First, the association rules        must include the fields Children, ChildrenAgeLess6,        ChildrenAgre6to12, ChildrenAgeMore12 of the table        CustomerPurchaseData in the body of the rule. Second, the        attribute Children must necessarily be present (this is        specified by R. Body). Third, the discovered patterns must have        one of the fields CategorySweets, CategoryCereal or        CategoryFruit as a consequent of the rule (specified by        R.Consequent). Finally, the discovered patterns must satisfy        certain thresholds measuring statistical significance (e.g.,        R.Confidence and R. Support).

Thus, this example data mining query specifies a set of patterns. Theset of these example patterns may indicate:

-   -   the extent to which families with children younger than six        years old buy sweets,    -   the extent to which families with children older than 12 years        old buy sweets,    -   the extent to which families with children older than 12 years        old buy fruit, etc.        Therefore, the pattern specified by the association rule:    -   Children=YES and ChildrenAgeLess6=YES→CategorySweets=YES (0.01,        0.55)        noted above is also one of the patterns specified by the data        mining query.

Pattern Templates are described in M. Klemmettinen et al., “FindingInteresting Rules for Large Sets of Discovered Association Rules”,Proceedings of the Third International Conference on Information andKnowledge Management, December, 1994. For example, a pattern templatemay be provided as follows:

-   -   Children and ChildrenAge *→Category(0.01,0.5)        where ChildrenAge and Category are generalizations of        attributes. Thus, if ChildrenAge specifies the set of attributes        {ChildrenAgeLess6, ChildrenAge6to12, ChildrenAgeMore12} and        Category specifies the set of attributes {CategorySweets,        CategoryCereal, CategoryFruit}, then this pattern template        specifies the same patterns as the above-described data mining        query.

II. Clustering Operator

The clustering operator receives, as input, a subset of rules and anattribute hierarchy of this subset. In particular, the attributehierarchy can be formed using the procedure described below withreference with FIG. 10. An example attribute hierarchy is illustrated inFIG. 13. All of the fields (e.g., attributes) of the attribute hierarchyare provided at the bottom of the attribute hierarchy. These fields areportions of the transaction file TRANS(Trans_ID, Cust_ID, C₁, . . .C_(n)) as described above, without the fields Trans_ID and Cust_ID. Inthe example hierarchy illustrated in FIG. 13, n=13.

A top portion of FIG. 10 shows an example procedure to generate theattribute hierarchy. In step 450, grouping data of a particular subsetof rules is determined by combining the fields of the TRANS file (e.g.,a table) into groups (e.g., fields C1, C2, C3 illustrated in FIG. 13 arecombined into group N1, fields C4 and C5 into group N2, etc.). In step455, these groups are further combined into larger groups, and so on.For example and as shown in FIG. 13, groups N2 and N3 are combined intogroup N4, groups N1 and N4 are combined into group N5, fields C9 and C10are combined into group N6, group N7 and field C11 are combined intogroup N8, groups N6 and N8 are combined into N9, and groups N5 and N9are combined into N10. As a result, the attribute hierarchy is generated(step 455), with attributes of the TRANS transaction file being itsleaves. It should be noted that a tree which defines this attributehierarchy (shown in FIG. 13) does not have to be balanced, e.g., allpath lengths from the root node to the leaves do not have to be equal.

The attribute hierarchy may include one or more (e.g., two) levels ofnodes below the descendent leaves of the attribute hierarchy (e.g., thefields of the TRANS transaction file). A first level consists of a pairof attributes—field and a relational operator. The relational operatormay include example operators such as “=”, “<”, “>”, etc. A second levelis below the first level and consists of three attributes—field,relational operator and sets of values which the field attribute can becompared to (e.g., predetermined values, one or more intervals, etc.).For example, the second level can be (C3, =, a) (e.g., field C3 uses therelational operator “=” to be compared to variable “a”), (C5, <, 20)(e.g., field C5, via the relational operator “<” is compared to number20), (C8, =, [60, 80]) (e.g., field C8, via the relational operator “=”is compared to a range between 60 and 80), etc. FIG. 14 shows an exampleillustration of the first and second level extensions of node N7. Inparticular, the first level of field C12 is a leaf 540, which containsfield C12 and a relational operator “<”. Below leaf 540, a lowest leafof field C12 (leaf 550) is provided with field C12, the relationaloperator “<” and a comparison value “20”. In addition, the first levelof field C13 is a leaf 545, which contains field C13 and a relationaloperator “=”. Below leaf 545, a lowest leaf of field C13 (leaf 555) isprovided with field C13, the relational operator “=” and a comparisonrange “[60, 80]”. These leaves are only provided for illustrativepurposes, and it should be understood that other combinations of fieldto relational operators to comparison values/ranges are possible. Thesehierarchies don't necessarily have to include the same number ofextensions/leaves. For example, field C12 may have two extensions, fieldC4 may have one extension, field C5 can have no extensions and field C6can have four extensions.

After the attribute hierarchy is generated in step 455 (shown in FIG.10), “Cut” data is generated with respect to the attribute hierarchy(step 460) by providing a “Cut” in the attribute hierarchy. “Cut” in theattribute hierarchy is defined as a set of nodes of the tree such that aunion of all descendant leaves of the nodes which were identified in thecut consists of all the fields of TRANS transaction file (e.g., C₁, . .. , C_(a)). An example cut is shown in FIG. 13 which includes thefollowing groups/fields: C1, C2, C3, N4, N6, C11 and N7. In addition,the “Cut” is not limited to the nodes of shown in FIG. 13, and can alsoinclude one or two levels below the field levels (shown in FIG. 14).FIG. 11 shows a detailed illustration of step 460 in which “Cut” data isgenerated. In step 480, the “Cut” is provided to the attributehierarchy. If the “Cut” is properly specified (e.g., all of the leavesof the attribute hierarchy are above the “Cut”, leaves being the lowestlevel of the attribute hierarchy) in step 485, or if the human expert(or the system) indicates that the “Cut” is unacceptable (step 490), adifferent “Cut” is created using similar techniques as described abovefor providing the original cut (step 497) and the procedure is restartedat step 485 with this newly created “Cut”. Otherwise, “Cut” data isgenerated as a function of the “Cut” (step 495) and can be stored inmemory for a possible future use.

After the “Cut” data is generated (step 460 in FIG. 10), subsets of theuser rules are grouped using “Cut” data and the hierarchy data (step465), and these grouped subsets are placed into Set S (step 470) to beprovided to the human expert.

Thus, the clustering operator consists of steps 460-470. As indicatedabove, the following data is provided as input to the clusteringoperator: a) initial set of user rules, b) an attribute hierarchy asdescribed above, and c) the “Cut”. The output of the clustering operatoris Set S which includes subsets of rules. These subsets are mutuallyexclusive and collectively exhaustive (e.g., a union of the subsets isequal to all of the rules in Set S).

FIG. 12 shows an example procedure for grouping subsets of the userrules using the “Cut” data as described for step 465 above (FIG. 10). Inparticular, all user rules are combined from a number of subsets of SetS to form Set A. In step 505, another set (e.g., a Cluster Working SetB) is initialized (e.g., to be an empty set or a null set). A new ruleis then retrieved from Set A (step 510). In step 515, if there are nomore rules in Set A to be analyzed or regrouped (e.g., Set A has no morerules or is a null set), the example procedure shown in FIG. 12 iscompleted. Otherwise, in step 520, it is determined if the new rulecorresponds to a class of any existing cluster subset in Set B. If thatis the case, the new rule is moved into a “matched” subset in Set B(step 525) and the procedure is directed to step 510. Otherwise, a newcluster subset is created in Set B (step 530), the new rule is moved tothe new cluster subset in Set B (step 535), and then the procedure isdirected to step 510.

Using the “Cut”, two rules are provided to the same class if and only ifthey have the same structure with respect to the “Cut”. In particular,the rules should have the same number of attributes and theseattributes, e.g., can be grouped in pairs so that two attributes in thesame pair have the same ancestor in the “Cut”. For example, the rules:

C1=5 and C4<6 and C9>8

C12=8

and

C1>3 and C6=5 and C10<2

C13<7

are equivalent because fields C4 and C6 (shown in FIG. 13) have group N4as an ancestor in the “Cut”, rules C9 and C10 have group N6 as anancestor in the “Cut”, and rules C12 and C13 have group N7 as anancestor in the “Cut”. It should be noted that the user rules in thesame cluster are “equivalent”. As such, a new rule retrieved from Set Acan be compared with any rule (or a specific rule) in the relatedcluster subset in Set B in step 520 shown in FIG. 12. In addition and asshown in FIG. 13, the rules:

C2=4 and C9=5

C12=8

and

C2=8 and C11=3

C12=6

are not equivalent because fields C9 and C11 do not have a commonancestor in the “Cut”. Accordingly, using the procedure shown in FIGS.10 and 12, the subsets of rules of the generated clusters are providedinto the set of regrouped rules generated in step 445 of FIG. 9.

After Set S is split into a subset of clusters, one or more statisticsmay be generated for each cluster. These statistics may be, e.g.,

-   -   the number of rules per cluster.    -   if a component of the rule is an attribute, the ranges of values        that such attribute can assume. For example, if the attribute is        “Age=a”, then it may be preferable to collect statistics on the        maximum and minimal values for the age in the rules for that        cluster, in addition to the average value and standard deviation        for that age.    -   for different nodes/groups, how many rules correspond to        different attributes for each node/group. For example, for group        N6 shown in FIG. 13, it is possible to maintain the number of        rules with attribute C9 and the number of rules with attribute        C10.    -   centers of clusters (calculated, e.g., with the method described        above and illustrated in FIGS. 4 and 5). These centers can be        reported to the human expert.        These example statistics may be utilized by the human expert in        step 410 (shown in FIG. 9) to determine which sets of rules the        human expert may select for a manual examination. This completes        the description of FIG. 9 and the way rules are examined by the        human expert.

If the human expert determines that the clustering of rules based on aparticular “Cut” is unsatisfactory, the rules may be regrouped in step445 using a different “Cut”. For example, this different cut would be afiner cut which generated a larger number of clusters (which are smallerin size). This can be done by merging back the clusters of rulesobtained with the previous “Cut” (in step 445), returning to step 410where the human expert marks all the merged rules as “undecided”, andthen, in step 445 again, re-cluster rules based on the different (e.g.,finer) “Cut”.

The process and system according to particular embodiments can beimplemented using, e.g., a graphical user interface (“GUI”) whichenables the human expert to communicate with the validation systemaccording to particular embodiments. Using this GUI, the human expertselects a number of operators from a graphical menu of the GUI. Exampleoperators provided on this graphical menu may include a “Filtering”operator, a “Clustering” operator and a “Browsing” operator (e.g.,allows the human expert to examine sets of rules generated by the“Clustering” operator or another operator). Other operators can also beincluded in the graphical menu of the GUI.

FIG. 15 shows an example flow of the process and system according toparticular embodiments. In particular, the user (e.g., human expert) canselect the “Filtering” operator from the graphical menu and apply thisoperator to Set S (step 600). As a part of the filtering operator, thehuman expert may specify a data mining query which selects “Good”, “Bad”or “undecided” rules from Set S. Then, in step 605, “Good” rules aremoved from Set S to “Good_Rules” set, and “Bad” rules are moved from SetS to “Bad_Rules” set which is, preferably, automatically saved by thesystem (e.g., the processor) into a memory device. In step 615, thesystem may mark the user rules which were determined by the user (orautomatically by the system) as “undecided”. In step 620, the humanexpert may apply the remaining “undecided” rules through another filterto again obtain “Good”, “Bad” and “undecided” rules (which can bedetermined using another user-specified data mining query) from the restof the rules. After the second “Filtering” operator is applied, thesystem may move “Good” rules from Set S to “Good_Rules” set, and “Bad”rules from Set S to “Bad_Rules” set (step 625). In step 640, the humanexpert may decide to cluster the remaining “undecided” rules in Set Susing the “Clustering” operator (which the human expert selects from thegraphical menu). The “Clustering” operator generates many sets of rulesthat the user may decide to examine using a graphical browser byselecting a “Browsing” operator from the graphic menu (step 645). The“Browsing” operator allows the user (e.g., the human expert) to examinethe clusters of generated user rules by analyzing the statistics(described above) for these clusters. This process of selectingoperators (from the graphical menu of available operators) can continueuntil, e.g., all the rules in Set S have been validated or until thehuman expert decides to stop the processing of the validation procedurebased on at least one of the above-described stopping criteria.

The human expert may apply a number of (e.g., four) operations insequence (e.g., two filtering operators, one clustering operator, andone browsing operator). This process can also be performed in parallel(e.g., the human expert may decide to perform two filtering operationsin parallel and then combine their results).

In particular embodiments, while the human expert proceeds deeper intoan validation process (e.g., performs more iterations of steps 410-430and 445 shown in FIG. 9), the process steps may be recorded using theGUI interface.

What is claimed is:
 1. A method comprising: accessing, by a computing device, at least a portion of a user profile that is based at least in part on historical data associated with a user; receiving, by a computing device, data indicative of a current state of the user from a remote system, wherein the current state of the user is the user's current activity; selecting, by a computing device, content by matching one or more attributes of the content to the portion of the user profile and the current state of the user; and providing, by a computing device, the selected content for display to the user.
 2. The method of claim 1, wherein the historical data associated with the user comprises the download history of the user.
 3. The method of claim 1, wherein the historical data associated with the user comprises the user's online purchase history.
 4. The method of claim 1, wherein the historical data associated with the user comprises the user's online transactions.
 5. The method of claim 1, wherein the current state of the user comprises the user's interactions with an application on a mobile device.
 6. The method of claim 5, wherein the current state of the user comprises the time the user is interacting with the application on the mobile device.
 7. The method of claim 1, wherein the content comprises an advertisement.
 8. The method of claim 1, wherein the content comprises digital media.
 9. An apparatus comprising: one or more processors; and one or more memories operatively coupled to at least one of the one or more processors and having instructions stored thereon that, when executed by at least one of the one or more processors, cause at least one of the one or more processors to: access at least a portion of a user profile that is based at least in part on historical data associated with a user; receive data indicative of a current state of the user from a remote system, wherein the current state of the user is the user's current activity; select content by matching one or more attributes of the content to the portion of the user profile and the current state of the user; and provide the selected content for display to the user.
 10. The apparatus of claim 9, wherein the historical data associated with the user comprises the download history of the user.
 11. The apparatus of claim 9, wherein the historical data associated with the user comprises the user's online purchase history.
 12. The apparatus of claim 9, wherein the historical data associated with the user comprises the user's online transactions.
 13. The apparatus of claim 9, wherein the current state of the user comprises the user's interactions with an application on a mobile device.
 14. The apparatus of claim 13, wherein the current state of the user comprises the time the user is interacting with the application on the mobile device.
 15. The apparatus of claim 9, wherein the content comprises an advertisement.
 16. The apparatus of claim 9, wherein the content comprises digital media.
 17. At least one non-transitory computer-readable medium storing computer-readable instructions that are operable, when executed by one or more computing devices, to cause at least one of the one or more computing devices to: access at least a portion of a user profile that is based at least in part on historical data associated with a user; receive data indicative of a current state of the user from a remote system, wherein the current state of the user is the user's current activity; select content by matching one or more attributes of the content to the portion of the user profile and the current state of the user; and provide the selected content for display to the user.
 18. The at least one non-transitory computer-readable medium of claim 17, wherein the historical data associated with the user comprises the download history of the user.
 19. The at least one non-transitory computer-readable medium of claim 17, wherein the current state of the user comprises the user's interactions with an application on a mobile device.
 20. The at least one non-transitory computer-readable medium of claim 17, wherein the content comprises an advertisement. 